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DETAILED ACTION 
Status of Claims 

1 . This action is in reply to the Application filed on 1 1 January 2005. 

2. Claims 1-27 are currently pending and have been examined. 

Information Disclosure Statement 

3. The Information Disclosure Statements filed 29 March 2006 and 2 August 2007 have been 
considered. Initialed copies of the Form 1449 are enclosed herewith. 



Drawings 

4. The drawings filed on 1 1 January 2005 are acceptable subject to correction of the informalities 
indicated on the attached "Notice of Draftsperson's Patent Drawing Review," PTO-948. In order to 
avoid abandonment of this application, correction is required in reply to the Office action. The 
correction will not be held in abeyance. 

5. New corrected drawings in compliance with 37 CFR 1.121(d) are required in this application because 
the drawings contain hand written notations. Applicant is advised to employ the services of a 
competent patent draftsperson outside the Office, as the U.S. Patent and Trademark Office no longer 
prepares new drawings. The corrected drawings are required in reply to the Office action to avoid 
abandonment of the application. The requirement for corrected drawings will not be held in abeyance. 



Claim Objections 

6. Claims 1-27 are objected to because of the following informalities: The claims are objected to for 
inconsistent terminology. Some of the claim language inconsistency is as follows: 

• compatible e Ban king server -^interface e Banking server -^interface server ->server bank's 
eBanking server -^computer server ->eBanking server ->eBanking interface server 

• IDOC -^formatted IDOC ->XML formatted IDOC 

• customers bank->bank 

There appears to be inconsistencies among all claims 1-27. The Examiner respectfully requests 
Applicants review all claims and make appropriate correction such that the claims contain consistent 
language. Appropriate correction is required. 



Claim Rejections - 35 USC §112 

7. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 



Application/Control Number: 10/521,499 
Art Unit: 3692 



Page 3 



The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter 
which the applicant regards as his invention. 

8. Claims 1-2, 4-27 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to 
particularly point out and distinctly claim the subject matter which applicant regards as the invention. 
Antecedent Basis: 

• Claim 1 recites the limitation "the customers location" in line 4. There is insufficient 
antecedent basis for this limitation in the claim. Appropriate correction is required. 

• Claim 1 recites the limitation "the customers system" in line 5. There is insufficient 
antecedent basis for this limitation in the claim. Appropriate correction is required. 

• Claim 4 recites the limitation "the RFC destination". There is insufficient antecedent basis for 
this limitation in the claim. Appropriate correction is required. 

• Claim 7 recites the limitation "the IDOC parameter" in line 2. There is insufficient antecedent 
basis for this limitation in the claim. Appropriate correction is required. 

• Claim 7 recites the limitation "the computer server" in line 13. There is insufficient antecedent 
basis for this limitation in the claim. Appropriate correction is required. 

Vague & Indefinite: 

• Claim 1 recites the limitation "the customers system" in line 12. Shouldn't this be the 
customers bank? Appropriate clarification and correction is required. 

• Claim 1 recites the limitation "said interface" in line 14. Shouldn't this be "said eBanking 
interface server"? Appropriate clarification and correction is required. 

• Claim 1 recites the limitation "the customers system" in line 17. Shouldn't this be the 
eBanking interface server? Appropriate clarification and correction is required. 

• Claim 1 recites the limitation "said server" in line 19. Shouldn't this be the said compatible 
eBanking server? Appropriate clarification and correction is required. 

• Claim 1 recites the limitation "said bank" in line 20. Shouldn't this be the customers bank? 
Appropriate clarification and correction is required. 

• Claim 1 recites the limitation "the IDCO" in line 20. Shouldn't this be the XML formatted 
IDOC? Appropriate clarification and correction is required. 

• Claim 2 recites the limitation "the banks eBanking server" in 2. Which server is this, the 
compatible server or the interface server? Appropriate clarification and correction is required. 

• Claim 2 recites the limitation "an XML formatted status document" in lines 2-3. Shouldn't this 
be the status be for the XML formatted IDOC? Also, lines 4-7 recite "status document", isn't 
the status document the XML formatted status document? Appropriate clarification and 
correction is required. 
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• Claim 4 recites the limitation "the IDOC to the RFC destination of the eBanking server" in line 
3-4. It is not clear what this is referring to since claim 1 indicates that the IDOC is in the RFC 
queue? Also is the "IDOC" referring to the initial IDOC or the XML formatted IDOC? 
Moreover, it is not clear what the RFC destination is since it is never previously recited. 
Could this recitiaton be attemting to recite "releasing the IDOC from the RFC queue to the 
eBanking interface server in the customers bank"? Appropriate clarification and correction is 
required. 

• Claim 4 recites the limitation "an RFC queue" in line 7. Is this a different RFC queue than 
that which was already recited in claim 1? Appropriate clarification and correction is required. 

• Claim 5 recites the limitation "the IDOC" in line 6. Is this the original IDOC or the XML 
formatted IDOC? Appropriate clarification and correction is required. 

• Claim 5 recites the limitation "the RFC queue" in line 6. Which RFC queue is this referring to, 
the one recited in claim 1 or 4? Appropriate clarification and correction is required. 

• Claim 6 recites the limitation "the IDOC" in line 5. Is this the original IDOC or the XML 
formatted IDOC? Appropriate clarification and correction is required. 

• Claim 6 recites the limitation "the RFC queue" in line 5. Which RFC queue is this referring to, 
the one in claim 1 or 4? Appropriate clarification and correction is required. 

• Claim 7 recites the limitation "storing IDOC data" in line 4. Shouldn't this be XML formatted 
IDOC data? Appropriate clarification and correction is required. 

• Claim 7 recites the limitation "the IDOC" in lines 5 and 6. Are these the XML formatted 
IDOC's? Appropriate clarification and correction is required. 

• Claim 7 recites the limitation "compiling the formatted IDOC and subsequent formatted 
IDOCs each into a transaction document formatted in extensible markup language (XML)". 
Claim 1 already indicates a properly formatted monetary transaction document as an 
intermediary document (IDOC) and the IDOC is then formatted into an XML document 
document. Therefore, doesn't claim 1 already cover the monetary transaction document 
being formatted from IDOC to XML? Appropriate clarification and correction is required. 

• Claim 7 recites the limitation "a digital signature" in lines 11 and 18, respectively. Are these 
the same digital signatures or different? Appropriate clarification and correction is required. 

• Claim 8 recites the limitation "the XML document" in liens 2-3. Is this referring to the XML 
formatted IDOC of claim 1 or not? Appropriate clarification and correction is required. 

• Claim 9 recites the limitation "IDOC status" in lines 3 and 8, respectively. Are these IDOC 
statuses the XML formatted IDOC statuses? Appropriate clarification and correction is 
required. 
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• Claim 9 recites the limitation "the bank" in line 9. Shouldn't this be the customers bank? 
Appropriate clarification and correction is required. 

• Claim 10 recites the limitation "the bank" in lines 2 and 9, respectively. Shouldn't this be the 
customers bank? Appropriate clarification and correction is required. 

• Claim 10 recites the limitation "an eBanking database" in line 6. Is this a different database 
than that recited in claim 4? Appropriate clarification and correction is required. 



The remainder of the claims are replete with similar inconsistencies. The Examiner respectfully request 
Applications review all claims for further inconsistencies. Appropriate correction and clarification is 
required for claims 1-27. 



Claim Rejections - 35 USC §103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections 

set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 
of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art 
to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was 
made. 

10. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that 
are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are 
summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 

11. Claims 1-3, 23-27 are rejected under 35 U.S.C. 103(a) as being unpatentable over Korman et al. (US 

(US 6308887) in view of Wenig et al. (US 6286098), Yee et al. (US 6738975), Nichols (WO 

01/33356), Hind et al. (US 7134075) and Clark et al. (US 5710889). 

Examiner's Note: The Examiner has pointed out particular references contained in the 
prior art of record within the body of this action for the convenience of the Applicant. 
Although the specified citations are representative of the teachings in the art and are 
applied to the specific limitations within the individual claim, other passages and figures 
may apply. Applicant, in preparing the response, should consider fully the entire 
reference as potentially teaching all or part of the claimed invention, as well as the 
context of the passage as taught by the prior art or disclosed by the Examiner. 
Claim 1 - 

A method for an automated banking system for permitting a customer of a bank to remotely authorize and 
request a computerized monetary transaction to be made by their bank, said method comprising: 
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• providing a computerized system at the customer's location; (see at least col. 3, II. 40-45, 54-56; 
col. 8, II. 38-41 ofKorman et al.) 

• receiving on the customer's system, a customer's manually inputted request, for the customer's 
bank to conduct a monetary transaction; (see at least col. 4, II. 49-67; col. 9, II. 33-38 ofKorman 
et al.) 

• automatically running on the customer's system, in response to a request, a monetary transaction 
program for generating a properly formatted monetary transaction document (see at least col. 3, 
II. 40-47; col. 9, II. 33-38 ofKorman et al.) 

• automatically transferring over a computer network the XML formatted IDOC from the customers 
system to a compatible eBanking server in the customer's bank; (see at least col. 3, II. 54-62; col. 
9, II. 11-25; Fig. Fig. 3 ofKorman) 

• automatically processing the requested monetary transaction via said server of said bank 
responding to the IDOC. (see at least col. 3, II. 54-62; col. 9, II. 11-25; Fig. Fig. 3 ofKorman) 

Korman et al. do not explicitly disclose: 

• properly formatted monetary transaction document as an intermediary document (IDOC); 

• automatically retaining in the customer's system the IDOC in a remote function call (RFC) queue, 
for a predetermined period of time, to permit the IDOC to be passed into an eBanking interface 
server of the customer's system for further processing; 

• programming said interface server to automatically convert the IDOC into an extensible markup 
language (XML) formatted document; 

Wenig et al. in view of Yee et al. teach properly formatted monetary transaction document as an 
intermediary document (IDOC) (see at least col. 4, II. 2-4, 9-10; col. 8, II. 56-58; col. 9, II. 58-60; col. 5, II. 
32-33 of Wenig et al.; see at least col. 8, II. 34-33 of Yee et al.). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to expand the method of Korman et al. to include and 
SAP R/3 viewer and SAP R/3 "intermediate document" format for commercial and e-commerce use as 
taught by Wenig et al. in view of Yee et al. One of ordinary skill in the art at the time of the invention 
would have been motivated to expand the method of Korman et al. in this way since it allows for particular 
events to be verified as having occurred during the user session, in other words, a client can show that he 
performed a particular transaction (e.g. made an electronic purchase) during the user session (see at 
least col. 2, II. 10-14 of Wenig etal.). 

Wenig et al. in view of Nichols and Clark et al. teach automatically retaining in the customer's system the 
IDOC in a remote function call (RFC) queue, for a predetermined period of time, to permit the IDOC to be 
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passed into an e Banking interface server of the customer's system for further processing (see at least col. 
3, II. 45-48; see at least col. 4, II. 13-20, 51-64 of Wenig et al.; pg. 20, II. 4-5 of Nichols; see at least col. 5, 
II. 30-36 of Clark et al.). It would have been obvious to one of ordinary skill in the art at the time of the 
invention to expand the method of Korman et al. to include application packages such as SAP's R/3 
Remote Function Calls as taught by Nichols, an auditor capture filter as taught by Wenig et al. and a 
repository that is a database within the GID that stores all messages sent through the GID in which 
transaction instructions messages are stored in the repository and are queued for onward transmission to 
the appropriate OLTPs at a permissible time as taught by Clark et al. One of ordinary skill in the art at the 
time of the invention would have been motivated to expand the method of Korman et al. in this way since 
it allows for particular events to be verified as having occurred during the user session, in other words, a 
client can show that he performed a particular transaction (e.g. made an electronic purchase) during the 
user session (see at least col. 2, II. 10-14 of Wenig etal.). 

Korman in view of Hind et al. teach programming said interface server to automatically convert the IDOC 
into an extensible markup language (XML) formatted document (see at least col. 9, II. 10-25, 33-38 of 
Korman et al.; col. 9, I. 50 through col. 10, I. 5; col. 16, II. 56-67; col. 18, II. 27-39 of Hind et al.). It would 
have been obvious to one of ordinary skill in the art at the time of the invention to expand the method of 
Korman et al. to include XML format and conversion as taught by Hind et al. One of ordinary skill in the 
art at the time of the invention would have been motivated to expand the method of Korman et al. in this 
way since in the Super-ATM structure, multiple destination transactions are supported where one 
transaction can result in different messages being routed to any number of destinations (see at least col. 
1, II. 34-37 of Korman etal.). 



Claim 2 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. teach the method of 
claim 1 as described above. Korman et al. in view of Wenig et al. further disclose: 

• automatically operating the bank's eBanking server to send an XML formatted status document to 
said customer; 

• automatically receiving said status document on the customer's system; 

• operating the customer's system to permit the customer to read the received status document; 

• automatically logging the received status document into a core transaction database memory in 
the customer's system. 

Korman et al. in view of Wenig et al. and Clark et al. teach automatically operating the bank's eBanking 
server to send an XML formatted status document to said customer; automatically receiving said status 
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document on the customer's system; operating the customer's system to permit the customer to read the 
received status document; automatically logging the received status document into a core transaction 
database memory in the customer's system (see at least col. 1, II. 53-55; col. 9, II. 15-25, 33-41; col. 10, II. 
15-20, 45-63 of Korman et al.; col. 3, II. 45-48, 65-66; col. 4, II. 5-10, 13-20, 51-64 of Wenig et al.; see at 
least col. 9, II. 44-46, 60-61, col. 10, II. 12-21, 26-31, 64-66 of Clark et al.). It would have been obvious to 
one of ordinary skill in the art at the time of the invention to expand the method of Korman to include (1) a 
series of communication steps between the Super-ATM, the host, and remote terminals in differing 
protocols as taught by Korman et al., (2) record ATM transactions at the ATM, (3) auditor storage for 
storing a user session as taught by Wenig et al., (4) customers receiving status and event information 
back form the OLTPs One of ordinary skill in the art at the time of the invention would have been 
motivated to expand the method of Korman et al. in this way since in the Super-ATM structure, multiple 
destination transactions are supported where one transaction can result in different messages being 
routed to any number of destinations (see at least col. 1 , II. 34-37 of Korman et al.). 

Claim 3 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. teach the method of 

claim 1 as described above. Korman et al. further disclose: 

• wherein the step of automatically running said monetary transaction program includes the steps 
of: entering parameters for the requested monetary transaction; creating a monetary transaction 
proposal; and executing a monetary transaction run to generate said IDOC. (see at least col. 1 , II. 
53-55; col. 9, II. 15-25, 33-41; col. 10, II. 15-20, 45-63 of Korman etal.) 

Claims 23-27 - 

Claims 23-27 are directed to an automated electronic banking system for initiating and automatically 
processing monetary transactions. Claim 23 recites substantially similar limitations as those addressed 
for claim 1. Claim 24 recites substantially similar limitations as those addressed for claim 19. Claims 25- 
26 recite substantially similar limitations as those addressed for claim 1. Claim 27 recites substantially 
similar limitations as those addressed for claim 2. Claims 23-27 are therefore rejected for the same 
reasons as set forth for claims 1-2 and 19. 

12. Claims 4-8, 10-13, 15, 17-22 are rejected under 35 U.S.C. 103(a) as being unpatentable over Korman 
et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. as applied to claims 1-3 
above, further in view of Evans (US 2004/0078340). 

Claim 4 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. teach the method of 
claim 1 as described above. Korman et al. further disclose: 
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• wherein said RFC queue retaining step includes the steps of: 

o releasing the I DOC to the RFC destination of the eBanking server in the customer's bank; 
(see at least col. 1, II. 53-55; col. 9, II. 15-18, 33-41; col. 10, II. 15-20, 45-63 of Korman et 
al.) 

Korman et al. do not explicitly disclose: 

o updating the I DOC status to a digitized code indicative of data being successfully passed 
to a port; 

o executing the IDOC received at the port into an RFC queue; 

Clark et al. teach updating the IDOC status to a digitized code indicative of data being successfully 
passed to a port; executing the IDOC received at the port into an RFC queue (see at least col. 10, II. 20- 
25, 25-29). It would have been obvious to one of ordinary skill in the art at the time of the invention to 
expand the method of Korman et al. to include the GID validating the message constructions and if the Tl 
does not require remote authorization, then queuing the Tl to the appropriate OLTP as taught by Clark et 
al. One of ordinary skill in the art at the time of the invention would have been motivated to expand the 
method of Korman et al. in this way since validating the construction of the message and validating the 
user, ensures that the message is in the proper format and that the user is entitled to the type of 
transaction requested for the particular account (see at least col. 10, II. 20-25 of Clark et al.). 

Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al.: 

• checking to determine if a communication link to said server in the customer's bank is active or 
inactive. 

Evans teach checking to determine if a communication link to said server in the customer's bank is active 
or inactive (see at least paragraphs [0154]-[0165] of Evans). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to expand the method of Korman et al. in view of 
Wenig et al., Yee et al., Nichols and Hind et al. and Clark et al. to include communications sequence 
pattern as taught by Evans. One of ordinary skill in the art at the time of the invention would have been 
motivated to expand the method of Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et 
al. and Clark et al. in this way since communications sequence pattern is used to manage the attempts to 
reach and establish communication link sessions with the device (see at least paragraph [0154] of 
Evans). 



Claim 5 - 
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Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al., further in view of 
Evans teach the method of claim 4 as described above. Evans at least at paragraphs [0154]-[0165] 
further teach: 

• responding to said interface server of said bank being inactive by increasing a number of retries 
counter by "1 "; 

• determining if the number of retires is greater than a predetermined maximum number; and 

• resubmitting the I DOC to the RFC queue if the number of retries does not exceed the maximum 
number; and 

• repeating said checking step. 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. to include 
communications sequence pattern as taught by Evans. One of ordinary skill in the art at the time of the 
invention would have been motivated to expand the method of Korman et al. in view of Wenig et al., Yee 
et al., Nichols and Hind et al. in this way since communications sequence pattern is used to manage the 
attempts to reach and establish communication link sessions with the device (see at least paragraph 
[0154] of Evans). 

Claim 6 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al., further in view of 
Evans teach the method of claim 5 as described above. Korman further disclose: 

• responding to the number of retries being greater than the predetermined number by notifying 
troubleshooting personnel of a problem in establishing a communication link with said interface 
server of the bank; (see at least col. 9, 1. 56 through col. 10, 1. 5 of Korman et al.) 

Korman et al. do not explicitly disclose: 

• resubmitting thelDOC to the RFC queue in response to a communication that the linkage problem 
has been resolved; and 

Wenig et al. teach resubmitting the IDOC to the RFC queue in response to a communication that the 
linkage problem has been resolved (see at least col. 4, I. 65 through col. 5, I. 13). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to expand the method of Korman et 
al. to include a unique session identification/state identification when the client and server environment 
are not in active communications (i.e. they are effectively disconnected) as taught by Wenig et al. One of 
ordinary skill in the art at the time of the invention would have been motivated to expand the method of 
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Kroman et al. in this way since using the session identification to attribute each request to a particular 
client server environment is able to handle client as if the client was continuously connected to the server 
environment (see at least col. 5, II. 10-13 of Wenig etal.). 

Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. do not explicitly disclose: 

• repeating said checking step. 

Evans teach repeating said checking step (see at least paragraphs [0154]-[0165] of Evans). It would 
have been obvious to one of ordinary skill in the art at the time of the invention to expand the method of 
Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. to include communications 
sequence pattern as taught by Evans. One of ordinary skill in the art at the time of the invention would 
have been motivated to expand the method of Korman et al. in view of Wenig et al., Yee et al., Nichols 
and Hind et al. in this way since communications sequence pattern is used to manage the attempts to 
reach and establish communication link sessions with the device (see at least paragraph [0154] of 
Evans). 

Claim 7 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 4 as described above. Korman further disclose: 

• responding to an active interface server by mapping the IDOC parameter fields to appropriate 
variables; (see at least col. 9, II. 10-45 of Korman et al.) 

• storing IDOC data in an eBanking DB (database); (see at least col. 10, II. 45-58 of Korman et al.) 

• compiling the formatted IDOC and subsequent formatted IDOCs each into a transaction 
document formatted in extensible markup language (XML); (see at least col. 9, II. 10-45 of 
Korman et al.) 

Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. do not explicitly disclose: 

• updating the IDOC status to indicate acceptable translation; 

• formatting the IDOC into instructions complying with a standard format implemented by the 
Society for Worldwide Data Bank Communication; 

• retrieving bank specific parameters from an eBanking. CNF configuration file; 

• creating a digital signature for each XML formatted document using client certificates; 

• establishing a secure connection to the computer server in the customer's bank; 

• determining whether a secure connection was successfully established; and 
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• responding to a successfully established secure connection by transferring over a computer 
network each transaction document containing transaction instructions and a digital signature to 
the computer server in the customer's bank. 



Clark et al. teach updating the IDOC status to indicate acceptable translation (see at least col. 10, II. 20- 
25); formatting the IDOC into instructions complying with a standard format implemented by the Society 
for Worldwide Data Bank Communication (see at least see at least col. 7, I. 50 through col. 9, I. 35J; 
retrieving bank specific parameters from an eBanking.CNF configuration file (see at least col. 7, I. 50 
through col. 9, 1. 35); establishing a secure connection to the computer server in the customer's bank (see 
at least col. 6, I. 36 through col. 7, I. 5); determining whether a secure connection was successfully 
established(see at least col. 6, I. 36 through col. 7, I. 5); creating a digital signature for each XML 
formatted document using client certificates (see at least col. 6, I. 36 through col. 7, I. 5); responding to a 
successfully established secure connection by transferring over a computer network each transaction 
document containing transaction instructions and a digital signature to the computer server in the 
customer's bank(see at least col. 6, I. 36 through col. 7, I. 5). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to expand the method of Korman et al. in view of 
Wenig et al., Yee et al., Nichols and Hind et al. to include message in SWIFT format, validating format, 
and encryption/decryption as taught by Clark et al. One of ordinary skill in the art at the time of the 
invention would have been motivated to expand the method of Korman et al. in view of Wenig et al., Yee 
et al., Nichols and Hind et al. in this way since the invention provide access to the electronic delivery 
system 24 hours a day, 365 days a year and encryption devices ensure data integrity and security (see at 
least col. 6, II. 25-27 and 36-38 of Clark et al.). 

Claim 8 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al., further in view of 
Evans teach the method of claim 7 as described above. Korman et al. in view of Wenig et al., Yee et al., 
Nichols and Hind et al., further in view of Clark et al. do not explicitly disclose: 

• further including the steps of responding to a failure to establish a secure connection by logging 
the XML document along with bank specific parameters into a database labeled "Failed Services'" 

• automatically retrying the successive steps of creating a digital signature, establishing a secure 
connection, and determining if a secure connection has been established; 

• determining whether the number of tries is greater than a predetermined maximum number; and 

• continuing said step of automatically retrying if the number of retries is not greater than the 
maximum number. 
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Evans teach repeating further including the steps of responding to a failure to establish a secure 
connection by logging the XML document along with bank specific parameters into a database labeled 
"Failed Services'"; automatically retrying the successive steps of creating a digital signature, establishing 
a secure connection, and determining if a secure connection has been established; determining whether 
the number of tries is greater than a predetermined maximum number; continuing said step of 
automatically retrying if the number of retries is not greater than the maximum number (see at least 
paragraphs [0154]-[0165] of Evans). It would have been obvious to one of ordinary skill in the art at the 
time of the invention to expand the method of Korman et al. in view of Wenig et al., Yee et al., Nichols 
and Hind et al. and Clark et al. to include communications sequence pattern as taught by Evans. One of 
ordinary skill in the art at the time of the invention would have been motivated to expand the method of 
Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. and Clark et al. in this way since 
communications sequence pattern is used to manage the attempts to reach and establish communication 
link sessions with the device (see at least paragraph [0154] of Evans). 

Claim 10 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 7 as described above. Clark et al. teaches: 

• waiting for a response over the computer network from the bank; (see at least col. 9, II. 44-46 of 
Clark et al.) 

• receiving from the bank a response document formatted in XML containing response status 
codes and messages for each of the monetary payment instructions posted to the customer's 
bank; (see at least col. 10, II. 65-66 of Clark et al.) 

• storing in an eBanking database the response document; (see at least col. 1 0, II. 29-33 of Clark et 
al.) 

• processing the statuses in the response document for each of the associated monetary 
transaction instructions; (see at least col. 10, II. 62-67 of Clark et al.) 

• determining the status from the bank of each monetary transaction, (see at least col. 10, II. 62- 
67). 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include a message flow for status and event data created by the OLTPs as 
taught by Clark et al. One of ordinary skill in the art at the time of the invention would have been 
motivated to expand the method of Korman et al. in this way since a customer that makes a high priority 
funds transfer will typically want to stay connected to the system waiting for confirmation that the 
transaction has occurred (see at least col. 10, II. 45-50 of Clark et al.). 
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Claim 11 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 10 as described above. Clark et al. teaches: 

• wherein the step of determining the status of each monetary transaction includes the step of 
indicating a status code equivalent to "OK" for monetary transactions successfully processed by 
the bank; (see at least col. 10, II. 1-8 of Clark et al.) 

• updating related IDOC statuses to have a code indicative of the bank having advised the 
monetary transaction was successfully made, (see at least col. 10, II. 1-8, 43-52 of Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include a message flow for status and event data created by the OLTPs as 
taught by Clark et al. One of ordinary skill in the art at the time of the invention would have been 
motivated to expand the method of Korman et al. in this way since a customer that makes a high priority 
funds transfer will typically want to stay connected to the system waiting for confirmation that the 
transaction has occurred (see at least col. 10, II. 45-50 of Clark et al.). 

Claim 12- 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 10 as described above. Clark et al. teaches: 

• further including the steps of indicating a status code corresponding to a Data Error causing the 
bank to reject the monetary transaction; (see at least col. 10, II. 1-8 of Clark et al.) 

• updating the IDOC status for the transaction to a code indication of the rejection due to a Data 
Error, (see at least col. 10, II. 1-8, 25-35 of Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include a message flow for status and event data created by the OLTPs as 
taught by Clark et al. One of ordinary skill in the art at the time of the invention would have been 
motivated to expand the method of Korman et al. in this way since a customer that makes a high priority 
funds transfer will typically want to stay connected to the system waiting for confirmation that the 
transaction has occurred (see at least col. 10, II. 45-50 of Clark et al.). 

Claim 13 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 12 as described above. Clark et al. teaches: 
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• further including sending an ... notification to an authorized officer of customer indication the 
reason for rejection of the monetary transaction; (see at least col. 14, 1. 61 through col. 15, II. 3; 
col. 16, II. 10-24; col. 17, II. 13-35 of Clark et al.) 

• determining by action of the authorized officer whether the rejection is valid; (see at least col. 14, 
I. 61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of Clark et al.) 

• responding to a valid rejection by action of the authorized officer to use an eBanking transaction 
request to reverse the monetary transaction request; (col. 5, II. 40-48, col. 20, II. 25-62 of Clark et 
al.) 

• correcting via action of the authorized officer, the data that caused the bank to reject the 
monetary transaction; (col. 5, II. 40-48, col. 20, II. 25-62 of Clark etal.) 

• reprocessing the corrected monetary transaction through said banking system for completion, 
(col. 5, II. 40-48, col. 20, II. 25-62 of Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include a protocol engine checking for errors base don information received 
back from the GID and to include contacting the customer support center to manually intervene in the 
process when an error occurs as taught by Clark et al. One of ordinary skill in the art at the time of the 
invention would have been motivated to expand the method of Korman in this way since manual 
intervention and a call to the customer support cent allows for diagnosis of what caused the difference in 
sequence numbers during the previous conversation (see at least col. 16, II. 18-22 of Clark). 

Kroman disclose 

• email notification (See at least col. 9, II. 60-65 of Korman et al.) 

Clark et al. do not explicitly disclose contacting customer support via email. However, Korman teaches 
contacting technicians to initiate a service call. Therefore it would have been obvious to include email 
notification in Clark since email is a way to initiate contact when service is required, (see at least col. 9, II. 
60-65 of Korman etal.) 

Claim 15 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 10 as described above. Clark et al. teaches: 

• further including the steps of indicating a status code corresponding to "Failed" for the bank failing 
to compete the monetary transaction fur unknown reasons; (see at least col. 14, 1. 61 through col. 
15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of Clark etal.) 
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• updating the response to "Failed" code in the IDOC status code indicative of the failed monetary 
transaction, (see at least col. 14, 1. 61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of 
Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include a protocol engine checking for errors base don information received 
back from the GID and to include contacting the customer support center to manually intervene in the 
process when an error occurs as taught by Clark et al. One of ordinary skill in the art at the time of the 
invention would have been motivated to expand the method of Korman in this way since manual 
intervention and a call to the customer support cent allows for diagnosis of what caused the difference in 
sequence numbers during the previous conversation (see at least col. 16, II. 18-22 of Clark). 

Claim 17- 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 10 as described above. Clark et al. teaches: 

• further including the steps of indicating from the bank either a return status code corresponding to 
"DUDE" for duplicate transmission by eBanking of a previous transmission rejected by the bank 
due to a Data Error or corresponding "DUOK"for a duplicate transmission by eBanking of a 
previous transmission successfully processed by the bank; (see at least col. 14, 1. 61 through col. 
15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of Clark et al.) 

• determining via the customer's computer system whether the return status code corresponds to 
DUDE or DUOK; (see at least col. 14, 1. 61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 
of Clark et al.) 

• determining in response to the status code of DUD whether the last IDOC status for the monetary 
transaction is indicative of the transaction being rejected by the bank due to Data Error; (see at 
least col. 14, 1. 61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of Clark et al.) 

• sending, in response to a rejection due to the Data Error, a ... notification to technical personnel 
for troubleshooting the reasons the monetary transaction was posted in duplicate to the bank; 
(col. 5, II. 40-48, col. 16, II. 10-24; col. 17, II. 13-35; col. 20, II. 25-62 of Clark et al.) 

• sending, in response to a rejection not being due to a Data Error, a notification to an authorized 
officer of customer to indicate reasons monetary transaction was rejected by bank. (col. 5, II. 40- 
48, col. 16, II. 10-24; col. 17, II. 13-35, col. 20, II. 25-62 of Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include a protocol engine checking for errors base don information received 
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back from the GID and to include contacting the customer support center to manually intervene in the 
process when an error occurs as taught by Clark et al. One of ordinary skill in the art at the time of the 
invention would have been motivated to expand the method of Korman in this way since manual 
intervention and a call to the customer support cent allows for diagnosis of what caused the difference in 
sequence numbers during the previous conversation (see at least col. 16, II. 18-22 of Clark). 

Kroman disclose 

• email notification (See at least col. 9, II. 60-65 of Korman et al.) 

Clark et al. do not explicitly disclose contacting customer support via email. However, Korman teaches 
contacting technicians to initiate a service call. Therefore it would have been obvious to include email 
notification in Clark since email is a way to initiate contact when service is required, (see at least col. 9, II. 
60-65 of Korman etal.) 

Claim 18- 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 17 as described above. Clark et al. teaches: 

• further including the steps of determining in response to a status code of "DUOK" whether the last 
I DOC status for the monetary transaction is indicative of successful processing of the transaction 
by the bank; (see at least col. 14, 1. 61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of 
Clark et al.) 

• changing the I DOC status to a code of indicative of successful processing, in response to a no 
answer in the immediately previous determining step; (see at least col. 14, 1. 61 through col. 15, II. 
3; col. 16, II. 10-24; col. 17, II. 13-35 of Clark etal.) 

• sending a... notification to an authorized officer of customer and customer's technical personnel, 
in response to a Yes answer in the previous associated determining step for indicating the 
monetary transaction was duplicated in said automated banking system, (see at least col. 14, 1. 
61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35 of Clark et al.) 

Kroman disclose 

• email notification (See at least col. 9, II. 60-65 of Korman et al.) 

Clark et al. do not explicitly disclose contacting customer support via email. However, Korman teaches 
contacting technicians to initiate a service call. Therefore it would have been obvious to include email 
notification in Clark since email is a way to initiate contact when service is required, (see at least col. 9, II. 
60-65 of Korman etal.) 
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Claim 19 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. teach the method of 
claim 1 as described above. Korman et al. teaches: 

• further including the steps of initiating by action of the customer using a scheduler a request for a 
bank statement, (see at least col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 7, II. 31-36 of Korman et 
al.) 

• passing the request to said interface server of customer for conversion into an XML document; 
(see at least col. 3, II. 54-62; col. 9, II. 11-25, 31-45; Fig. Fig. 3 of Korman) 

• sending an e-mail in response to the number of retires exceeding the maximum number to an 
officer of customer and technical personnel to advise of the connection or statement retrieval 
failure; (see at least col. 9, 1. 56 through cot. 10, I. 5 of Korman et al.) 

Korman et al. do not explicitly disclose: 

• retrieving required parameters from an eBanking configuration file necessary to establish a 
secure socket layer (SSL) session over said computer network; 

• establishing over said computer network a secure connection to the banks eBanking server; 

• raising a "Failure" exception to the scheduler for permitting a manual request for the statement. 

Clark et al. teach retrieving required parameters from an eBanking configuration file necessary to 
establish a secure socket layer (SSL) session over said computer network (see at least col. 6, I. 36 
through col. 7, I. 5); establishing over said computer network a secure connection to the banks eBanking 
server (see at least col. 6, I. 36 through col. 7, I. 5). It would have been obvious to one of ordinary skill in 
the art at the time of the invention to expand the method of Korman et al. in view of Wenig et al., Yee et 
al., Nichols and Hind etal. to include encryption/decryption as taught by Clark et al. One of ordinary skill 
in the art at the time of the invention would have been motivated to expand the method of Korman et al. in 
view of Wenig et al., Yee et al., Nichols and Hind et al. in this way since encryption devices ensure data 
integrity and security (see at least col. 6, II. 25-27 and 36-38 of Clark et al.). 

Clark et al. teach raising a "Failure" exception to the scheduler for permitting a manual request for the 
statement (see at least col. 5, II. 40-48, col. 14, I. 61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13- 
35, col. 20, II. 25-62 of Clark et al). It would have been obvious to one of ordinary skill in the art at the 
time of the invention to expand the method of Korman et al. to include a protocol engine checking for 
errors base don information received back from the GID and to include contacting the customer support 
center to manually intervene in the process when an error occurs as taught by Clark et al. One of 
ordinary skill in the art at the time of the invention would have been motivated to expand the method of 
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Korman in this way since manual intervention and a call to the customer support cent allows for diagnosis 
of what caused the difference in sequence numbers during the previous conversation (see at least col. 
16, II. 18-22 of Clark). 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. do not explicitly 
disclose: 

• determining if the connection is successfully established; 

• determining in response to an unsuccessful connection whether a number of retries is greater 
than an allowed maximum number; 

• repeating said secure connecting establishing step in response to the number of retries not 
exceeding the maximum number; 

Evans teach determining if the connection is successfully established; determining in response to an 
unsuccessful connection whether a number of retries is greater than an allowed maximum number ; 
repeating said secure connecting establishing step in response to the number of retries not exceeding the 
maximum number (see at least paragraphs [0154]-[0165] of Evans). It would have been obvious to one 
of ordinary skill in the art at the time of the invention to expand the method of Korman et al. in view of 
Wenig et al., Yee et al., Nichols and Hind et al. and Clark et al. to include communications sequence 
pattern as taught by Evans. One of ordinary skill in the art at the time of the invention would have been 
motivated to expand the method of Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et 
al. and Clark et al. in this way since communications sequence pattern is used to manage the attempts to 
reach and establish communication link sessions with the device (see at least paragraph [0154] of 
Evans). 

Claim 20 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 19 as described above. Korman et al. teaches: 

• further including the steps of responding to a successful connection in said secure connection 
establishing step by posting the XML document containing statement request parameters to the 
bank's eBanking server; (col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 7, II. 31-36, col. 9, II. 10-45 of 
Korman et al.) 

• retrieving on customer's system statements(s) in XML formatted response form the bank; (see at 
least col. 9, II. 10-45, col. 7, II. 31-36 of Korman et al.) 

• storing both the XML formatted requests and response in an eBanking database of the customer; 
(see at least col. 1, II. 53-55; col. 4, II. 42-45 of Korman et al.) 
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• retrieving the statement from the eBanking database to create a file in a designated folder; (see 
at least col. 9, II. 10-45, col. 7, II. 31-36 ofKorman et al.) 

• reconciling the statements through use of standardized banking business software, (see at least 
col. 9, II. 10-45, col. 7, II. 31-36 ofKorman etal.) 

Claim 21 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. teach the method of 
claim 1 as described above. Korman et al. teaches: 

• initiating by action of the customer using an eBanking transaction code for requesting a statement 
showing the completed monetary transactions; (col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 7, II. 
31-36, col. 9, II. 10-45 ofKorman et al.) 

• converting, via said interface server of customer, the request into an XML formatted document; 
(col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 7, II. 31-36, col. 9, II. 10-45 ofKorman et al.) 

Korman et al. do not explicitly disclose: 

• retrieving required parameters from an eBanking configuration file necessary to establish a 
secure connection over the computer network to an eBanking server of the bank; 

• establishing over said computer network a secure connection to the banks eBanking server; 

Clark et al. teach retrieving required parameters from an eBanking configuration file necessary to 
establish a secure connection over the computer network to an eBanking server of the bank (see at least 
col. 6, 1. 36 through col. 7, 1. 5); establishing over said computer network a secure connection to the banks 
eBanking server (see at least col. 6, I. 36 through col. 7, I. 5). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to expand the method of Korman et al. in view of 
Wenig et al., Yee et al., Nichols and Hind et al. to include encryption/decryption as taught by Clark et al. 
One of ordinary skill in the art at the time of the invention would have been motivated to expand the 
method of Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. in this way since 
encryption devices ensure data integrity and security (see at least col. 6, II. 25-27 and 36-38 of Clark et 
al.). 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. do not explicitly 
disclose: 

• determining if the connection is successfully established; and 

• responding to an unsuccessful establishment of the connection by returning a connection error 
message for display to the customer. 
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Evans teach determining if the connection is successfully established; responding to an unsuccessful 
establishment of the connection by returning a connection error message for display to the customer (see 
at least paragraphs [0154]-[0165] of Evans). It would have been obvious to one of ordinary skill in the art 
at the time of the invention to expand the method of Korman et al. in view of Wenig et al., Yee et al., 
Nichols and Hind et al. and Clark et al. to include communications sequence pattern as taught by Evans. 
One of ordinary skill in the art at the time of the invention would have been motivated to expand the 
method of Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. and Clark et al. in this 
way since communications sequence pattern is used to manage the attempts to reach and establish 
communication link sessions with the device (see at least paragraph [0154] of Evans). 

Claim 22 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. further in view of 
Evans teach the method of claim 21 as described above. Korman et al. teaches: 

• further including the steps of responding to the successful establishment of the connection by 
posting to the eBanking server of the bank the XML document containing the statement request 
parameters; (col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 7, II. 31-36, col. 9, II. 10-45 of Korman et 
al.) 

• receiving on the eBanking interface server of the customer a response from the bank of the XML 
formatted statement; (col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 7, II. 31-36, col. 9, II. 10-45 of 
Korman et al.) 

• extracting the statement for display to the customer, (col. 3, II. 40-45, 54-56; col. 8, II. 38-41, col. 
7, II. 31-36, col. 9, II. 10-45 of Korman etal.) 

13. Claims 9, 14 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Korman et al. in 
view of Wenig et al., Yee et al., Nichols, Hind et al. and Clark et al. as applied to claims 1-3 above, 
further in view of Evans as applied to claims 4-8, 10-13, 15, 17-22 above further in view of Jacobs 
(WO 98/56024). 

Claim 9 - 

Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al., Clark et al. further in view of 
Evans teach the method of claim 8 as described above. Clark et al. and Jacob teach: 

• further including the steps of responding to the number of retries exceeding the maximum number 
by updating the I DOC status to a code of inactive of an error while posting payments (see at least 
paragraphs [01 54]-[01 65] of Evans; see at least col. 13, II. 9-24; col. 14, 1. 61 through col. 15, II. 3; 
col. 16, II. 10-24; col. 17, II. 13-35 of Clark et al.) 
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It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al. to include 
communications sequence pattern as taught by Evans and to include when there is a failure to queue a 
SND file and a re-try is attempted, a SYSTEM. ERR file is created, the business application can then be 
shut down and an operator summoned as taught by Clark et al. One of ordinary skill in the art at the time 
of the invention would have been motivated to expand the method of Korman et al. in view of Wenig et 
al., Yee et al., Nichols and Hind et al. in this way since communications sequence pattern is used to 
manage the attempts to reach and establish communication link sessions with the device (see at least 
paragraph [0154] of Evans) and to notify an operator when an SYSTEM. ERR occurs (see at least col. 13, 
II. 10-24 of Clark). 

Clark in view of Jacobs further teach: 

• sending a ... notification to an authorized officer of customer for release of the payment via prior 
conventionally established telex or facsimile transmission; (see at least col. 14, 1. 61 through col. 
15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35; col. 5, II. 40-48, col. 20, II. 25-62 of Clark et al.; see at 
least pg. 20, II. 10-11 of Jacobs) 

• responding to the notification, the authorized officer releases or provides the monetary 
transaction documents via telex or facsimile to the bank; (see at least col. 10, II. 3-7 of Clark et 
al.; see at least pg. 20, II. 10-11 of Jacobs) 

• updating the IDOC status code to indicate the monetary transaction successful completion has 
been acknowledged by the bank, (see at least col. 10, II. 25-35 of Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include manual intervention as taught by Clark et al. and sending the 
messages via telex or fax to the bank as taught by Jacobs. One of ordinary skill in the art at the time of 
the invention would have been motivated to expand the method of Korman in this way since a customer 
that makes a high priority funds transfer will typically want to stay connected tot eh system waiting for 
confirmation that the transaction has occurred (see at least col. 10, II. 45-50 of Clark et al.). 

Kroman disclose 

• email notification (see at least col. 9, II. 60-65 of Korman et al.) 

Clark et al. do not explicitly disclose contacting customer support via email. However, Korman teaches 
contacting technicians to initiate a service call. Therefore it would have been obvious to include email 
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notification in Clark since email is a way to initiate contact when service is required, (see at least col. 9, II. 
60-65 of Korman etal.) 

Claim 14- 

Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al., Clark et al. further in view of 
Evans teach the method of claim 13 as described above. Clark and Jacob teach: 

• further including the steps of responding to an invalid rejection by action of the authorized officer 
using appropriate eBanking transaction codes for releasing the monetary transaction via tested 
telex transmission to the bank; (see at least col. 14, I. 61 through col. 15, II. 3; col. 16, II. 10-24; 
col. 17, II. 13-35; col. 5, II. 40-48, col. 20, II. 25-62 of Clark et al.; see at least pg. 20, II. 10-11 of 
Jacobs) 

• receiving via the customer's computer system an acknowledgement form the bank confirming 
completion of the monetary transaction, (see at least col. 10, II. 25-35 of Clark et al.) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include manual intervention as taught by Clark et al. and sending the 
messages via telex or fax to the bank as taught by Jacobs. One of ordinary skill in the art at the time of 
the invention would have been motivated to expand the method of Korman in this way since a customer 
that makes a high priority funds transfer will typically want to stay connected tot eh system waiting for 
confirmation that the transaction has occurred (see at least col. 10, II. 45-50 of Clark et al.). 

Kroman disclose 

• email notification (see at least col. 9, II. 60-65 of Korman et al.) 

Clark et al. do not explicitly disclose contacting customer support via email. However, Korman teaches 
contacting technicians to initiate a service call. Therefore it would have been obvious to include email 
notification in Clark since email is a way to initiate contact when service is required, (see at least col. 9, II. 
60-65 of Korman etal.) 

Claim 16- 

Korman et al. in view of Wenig et al., Yee et al., Nichols and Hind et al., Clark et al. further in view of 
Evans teach the method of claim 1 5 as described above. Evans in view of Clark et al. further teach: 

• further including the steps of sending via . . . notification from the bank to the authorized officer the 
reasons for the failure by the bank to complete the monetary transaction; (see at least col. 14, 1. 
61 through col. 15, II. 3; col. 16, II. 10-24; col. 17, II. 13-35; col. 5, II. 40-48, col. 20, II. 25-62 of 
Clark et al.; see at least pg. 20, II. 10-11 of Jacobs) 
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• releasing by action of the authorized officer using an appropriate eBanking transaction code via 
tested telex or facsimile authorization to the bank to complete the monetary transaction; (see at 
least pg. 20, II. 10-11 of Jacobs) 

• receiving via telex or facsimile from the bank to the customer confirmation that the monetary 
transaction was completed, (see at least pg. 20, II. 10-11 of Jacobs) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to expand the 
method of Korman et al. to include manual intervention as taught by Clark et al. and sending the 
messages via telex or fax to the bank as taught by Jacobs. One of ordinary skill in the art at the time of 
the invention would have been motivated to expand the method of Korman in this way since a customer 
that makes a high priority funds transfer will typically want to stay connected tot eh system waiting for 
confirmation that the transaction has occurred (see at least col. 10, II. 45-50 of Clark et al.). 

Kroman disclose 

• email notification (see at least col. 9, II. 60-65 of Korman et al.) 

Clark et al. do not explicitly disclose contacting customer support via email. However, Korman teaches 
contacting technicians to initiate a service call. Therefore it would have been obvious to include email 
notification in Clark since email is a way to initiate contact when service is required, (see at least col. 9, II. 
60-65 of Korman etal.) 

Conclusion 

Any inquiry concerning this communication or earlier communications from the examiner should 
be directed to SARAH M. MONFELDT whose telephone number is (571)270-1833. The examiner can 
normally be reached on Monday-Friday 7:30am-5:00pm (EST) ALT Fridays off. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Kambiz Abdi can be reached on (571)272-6702. The fax phone number for the organization where this 
application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) 
at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative 
or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272- 
1000. 
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